心路历程：vue2.0+webpack+koa2 前后端同构实践（一）

吐槽篇

做了vue2.0 + webpack + koa前后端同构实践，有几点想吐槽下：

es6

看源码先学es6，接着还得学babel。一直没有在正式项目中引入es6，虽然写es6是流行、是趋势，但是非必须，目的是让项目在不断迭代同时技术能平稳过渡，秉持少做就是少错————babel相关问题也省了。

.vue

这次用了.vue文件，用.vue文件最重要的原因是想用类是fis中同名依赖的方案，不想在js里面写一句require（style.css）如此丑爆了的代码，最后发现在vscode里面对.vue文件的js不做语法校验（用的是eslint），又得查资料（目前依然没有解决）。

vue-loader有两点很方便：

1. scope

2. 不用去手动去写css、template的依赖

关于第二点，我觉得带来一个问题，在vscode中做eslint语法检查或者格式化html内的css、js。目前格式化还勉强可以，但是elint语法检查还没有没有解决。

extract-text-webpack-plugin有个坑（不知道算不算bug）需要特别注意Order in output CSS file
大致原因应该是在引入了路由后导致的，不用.vue文件在这种场景下一样会有问题。

vue2.0

vue2.0的初步尝试，要在服务端渲染，必须用新的方法render来代替template，那么问题又来了，官方例子中在render中用的是jsx（和react的jsx相近），而且和写vue模版绑定方式有区别，也没找到双向绑定的方案，如果加上vuex使用单向数据流好像没什么问题。还有就是，不能格式化代码了，没找到可以js中混用的jsx的格式化插件，或者像类似fis里的__inline功能的插件（突然好怀念fis）

顺带吐槽下1.0，在绑定事件的时候发现一个坑

<div @anyevent="anymethod
 "></div>

通过this.$emit('anyevent')无法触发anymethod。找了我好半天才看出端倪
最后发现是因为刚好在anymethod后换行了，方法名后面多了一个空格没看出来。
删除空格后就正常了，但这算不算vue的bug呢？

koa2

vue2.0提供了写入流的接口，防止编译字符串过大而引发阻塞，好东西得用啊，but，问题又来了

http://koa.bootcss.com/#context
Koa 不支持 直接调用底层 res 进行响应处理。请避免使用以下 node 属性：

• res.statusCode

• res.writeHead()

• res.write()

• res.end()

koa里提供的api禁止调用底层的方法写流（不是完全禁止）。又得找方案。

webpack

vue2.0和koa的开发体验很不错，但构建工具却十分不省心，用了几周webpack，依然对它没有好感，fis3之前一直用的挺好。https://www.zhihu.com/questio...

fis3

至于为什么没有继续用fis3，最主要是几个痛点：

• fis的构建流程，容易理解，过程可控，但到深入使用发现有些流程并不合理，比如为什么要先单文件编译，比如压缩、加md5，为什么不等打包阶段后对最后对产出物进行这样的编译的呢，虽然可以通过配置达到效果，但这个使得fis的配置复杂度增加，如果一定要这样，反而觉得gulp这种基于任务的方式更灵活。

• fis不是专门做打包的工具，所以webpack这方面确实更胜一筹。个人觉得有了打包方案，seajs，requirejs,或者modjs这类前端加载器成了鸡肋。

• 至于生态比不上webpack，对我来说只是瘙痒，最后还是看如何适应用户需求，提升开发体验.

大小写

开发时，用的是window系统，迁移到linux服务器上编译源码时，发现找不到vuex模块，原来是window不区分大小写，所以编译通过了

import Vuex from 'Vuex'  // 错误的写法vuex的包名是小写的
import Vuex from 'vuex'  // 正确的写法

node 版本选择

线上运行的是Node v5.12.0 (Stable)

开始的选型是Node v4.4.7 (LTS)，考虑到强依赖的第三方包需要支持NPM 3，考虑到稳定性不敢太激进的使用最新的6.x，则总选了最新的stable

大致的思路不算严谨，因为目前只是用来开发辅助功能，对node研究不是太深，只能暂定这个方案。

ES6的支持

Node v5.12.0 (Stable)对ES6兼容性还有一些问题
例如: let const，需要在严格模式下才能使用